Connected with the development of all but the most trivial of computer software programs is the need for debugging. Debugging refers to the process of detecting and removing defects or “bugs” from computer programs. In commercial software development, debugging often consumes considerable time, and may account for the largest time component in a development project. Traditional bug fixing requires detailed communication between testers and developers. Time is often wasted going back and forth between testers and developers trying to reproduce and isolate problems. Verifying that a bug has been fixed is error-prone and time consuming. Because fixing defects can be time-consuming and unpredictable, commercial software is frequently released with hundreds of open bug reports, release schedules are delayed while developers resolve open issues, and helpdesk tickets stay open while problems remain unresolved. Therefore, software developers are continually looking for ways to reduce the amount of time spent on debugging.
Conventional Debuggers
One tool commonly used to expedite debugging is a debugger computer program for locating defects in another computer program. Typically, a debugger operates by monitoring or observing an execution of a computer program. When the executing computer program generates an unrecoverable fault or exception caused by a defect or bug in the computer program, the debugger provides information about the state of the execution at the execution point the fault or exception occurred.
Some debuggers facilitate the setting of breakpoints. A breakpoint is a forced stop or pause (i.e., break) in the execution of a computer program being monitored or observed by the debugger. Typically, a debugger sets a breakpoint in a computer program by modifying or instrumenting the instructions of the computer program so that when a particular instruction is reached during execution, the execution is paused and control of the execution is transferred to the debugger. While the execution is paused and under control of the debugger, development or testing personnel can use the debugger to perform various investigative and debugging activities such as inspecting the state of the computer program, executing the computer program one instruction at a time (step-by-step), allowing program execution to continue to the next breakpoint, and setting new breakpoints.
To set a breakpoint with a debugger, typically the user of the debugger specifies a source code line number corresponding to an executable instruction of the computer program. For example, the source code line number may correspond to a particular function or sub-routine hypothesized to contain a defect. Each time the instruction is reached during execution of the program, which may be multiple times if the instruction is executed in a loop, the execution breaks at the instruction. However, if the instruction is executed in a loop, breaking execution of the program each time the instruction is executed can become tedious or impractical, especially if the defect occurs only after the Nth execution of the instruction where N is a relatively large number in the hundreds, thousands, or even millions.
Some debuggers allow users to set conditional instruction breakpoints. A conditional breakpoint is an instruction breakpoint but with a condition that is evaluated by the debugger each time the instruction is reached during execution of the program under test. With a conditional breakpoint, the execution of the program breaks at the breakpoint only if the condition associated with the breakpoint is met. Typically, conditions are expressed in the form of a Boolean expression on the state of program variables such as local and global variables.
Some debuggers allow users to set watchpoints. A watchpoint is similar to a conditional breakpoint except that a watchpoint is a condition associated with a program variable instead of a condition associated with a line number or instruction. Anytime during execution that the watched program variable changes to a state that satisfies the watchpoint condition, the debugger breaks the execution after the instruction causing the state change.
Computer Program Execution Record and Replay Systems
A computer program execution record and replay system records information about a program under test as the program executes, and provides reports about that information. Some systems facilitate replaying recorded program execution on a repeated basis. Using these computer execution record and replay systems, debugging is improved because defects are reproducible by replaying a particular recorded program execution session. A debugger may be used to observe and analyze the defects reproducible with these replay systems.
Often, a defect that occurs during recording of a program execution does not occur until many hours or even many days after the recording is started. For example, the program may be a complex server-based web application that serves many clients and is connected to multiple databases and that develops defects only under certain operating conditions such as a heavy client load. When debugging a recorded execution using a debugger and a replay system, it is desirable to be able to precisely break the replay execution at or near the point during the replay execution when a defect is reproduced.
One approach for breaking a replay execution using a breakpoint includes a user setting an instruction breakpoint, conditional breakpoint or watchpoint in the program using a debugging tool. However, these solutions are less than optimal. An instruction breakpoint is not optimal because the replay execution will break each time the instruction is executed, which may be hundreds, thousands, or millions of times before the defect is reproduced. Conditional breakpoints and watchpoints are not optimal because the user may not have sufficient information at hand about the state of program variables to formulate a condition that causes the replay execution to break at the precise moment. Therefore, a user is currently required to make a best guess as to an instruction breakpoint, conditional breakpoint, or watchpoint that will break the replay execution at the desired time. With the current approach, there is no effort to leverage the use of the record and replay system as a means to help facilitate the setting of breakpoints. At best, the current approach provides one with a tedious and time-consuming task.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.